After completing the hardware architecture of the single-socket IoT energy meter, the next critical stage was implementing reliable energy calculation and data handling on the ESP32.

Unlike simple voltage or current monitoring, a kWh system must continuously compute power and accumulate energy over time. This requires careful handling of sampling intervals, communication reliability, and data persistence.

image.png

Reading Electrical Parameters

The system uses the PZEM-004T module to obtain:

  • Voltage (V)
  • Current (A)
  • Active Power (W)
  • Energy (kWh)
  • Frequency (Hz)

Communication between ESP32 and PZEM is handled via UART.

image.png

A periodic polling method is implemented to read data every defined interval (typically 1–2 seconds).

To avoid unstable readings:

  • Invalid responses are filtered
  • Communication timeout is monitored
  • Re-read attempts are implemented if data is corrupted

This ensures stable long-term monitoring.

Energy Accumulation Strategy

Although the PZEM module provides accumulated energy internally, I implemented additional logic on the ESP32 for:

  • Energy reset functionality
  • Session-based energy tracking
  • Cost calculation (based on Rp/kWh tariff)

Energy cost is calculated using:

Cost = Energy (kWh) × Tariff (Rp/kWh)

image.png

The tariff value can be configured remotely depending on the electricity pricing scheme.

WiFi Connectivity Handling

Because the device operates in real environments, WiFi stability cannot be assumed.

The firmware includes:

  • Auto-reconnect routine
  • Offline detection (fallback to local LCD monitoring)
  • Timeout-based retry logic

If WiFi is unavailable for a defined period, the system continues measuring locally and resumes cloud synchronization once the connection is restored.

Data Logging Architecture

image.png

All measurement data is transmitted to Firebase Realtime Database using HTTPS-based secure communication.

The structured data tree includes:

  • voltage
  • current
  • power
  • energy
  • cost
  • alert
  • timestamp

Each measurement cycle updates the corresponding fields in the database. Separating measurement logic from communication logic ensures modular firmware design.

This architecture allows:

  • Real-time remote monitoring
  • Historical data visualization
  • Cloud-based alert evaluation
  • Scalability for multiple devices

By isolating the Firebase client functions from core measurement routines, the firmware remains adaptable for future platform expansion without modifying the energy calculation engine.

Relay Control Logic (Threshold-Based Warning System)

Instead, a threshold-based warning mechanism is implemented.

When:

Energy ≥ Configured Limit

image.png

The system will:

· Set an alert flag in Firebase

· Display warning information on the LCD

· Trigger remote notification via the cloud layer

The load remains active unless manually switched OFF.

This design choice improves safety and avoids unintended service interruption while still providing preventive energy monitoring.

Design Lessons

Accurate kWh monitoring is not only about measuring voltage and current. It requires:

  • Stable communication
  • Robust error handling
  • Persistent data logic
  • Proper integration between measurement and cloud layer

This firmware architecture became the backbone for the multi-socket and advanced IoT versions developed afterward.

#Embedded# #ESP32# #iot# #internet of things# #firebase# #kwh meter#

#Embedded#
#ESP32#
#iot#
#internetofthings#
#firebase#
#kwhmeter#
IoT Project

No comments yet. Be the first to comment!